Programs written in the Java programming language (Java is a trademark of Sun Microsystems Inc) are generally run in a virtual machine environment, rather than directly on hardware. Thus a Java program is typically compiled into byte-code form, and then interpreted by a Java virtual machine (VM) into hardware commands for the platform on which the Java VM is executing. The Java VM itself is an application running on the underlying operating system. An important advantage of this approach is that Java applications can run on a very wide range of platforms, providing of course that a Java VM is available for each platform.
Java is an object-oriented language. Thus a Java program is formed from a set of class files having methods that represent sequences of instructions. One Java object can call a method in another Java object. A hierarchy of classes can be defined, with each class inheriting properties (including methods) from those classes which are above it in the hierarchy. For any given class in the hierarchy, its descendants (i.e. below it) are called subclasses, whilst its ancestors (i.e. above it) are called superclasses.
At run-time classes are loaded into the Java VM by one or more class loaders, which are themselves organised into a hierarchy. Objects can then be created as instantiations of these class files, and indeed the class files themselves are effectively loaded as objects. In recent years the Java environment has become very popular, and is described in many books, for example “Exploring Java” by Niemeyer and Peck, O'Reilly & Associates, 1996, USA, and “The Java Virtual Machine Specification” by Lindholm and Yellin, Addison-Wedley, 1997, USA.
The standard Java VM architecture is generally designed to run only a single application, although this can be multi-threaded. In a server environment used for database transactions and such-like, each transaction is typically performed as a separate application, rather than as different threads within an application. This is to ensure that every transaction starts with the Java VM in a clean state. In other words, a new Java VM is started for each transaction. Unfortunately however this results in an initial delay in running the application (the reasons for this will be described in more detail later). The overhead due to having to start up (and then stop) a fresh Java VM for each new application can seriously degrade the scalability of Java server solutions.
Various attempts have been made to mitigate this problem. EP-962860-A describes a process whereby one Java VM can fork into a parent and a child process, this being quicker than setting up a fresh Java VM. The ability to run multiple processes in a Java-like system, thereby reducing overhead per application, is described in “Processes in KaffeOS: Isolation, Resource Management, and Sharing in Java” by G Back, W Hsieh, and J Leprean (see: /flux/papers/kaffeos-osdi00/main.html at cs.utah.edu). Another approach is described in “Oracle JServer Scalability and Performance” by Jeremy Litzt, July 1999 (see: database/documents/jserver_scalability_and_performance_twp.pdf at
The JServer product available from Oracle Corporation, USA, supports the concept of multiple sessions (a session effectively representing a transaction or application). Resources such as read-only bytecode information are shared between the various sessions, but each individual session appears to its client to be a dedicated conventional Java VM.
U.S. patent application Ser. No. 09/304,160, filed Apr. 30, 1999 (“A long Running Reusable Extendible Virtual Machine”), assigned to IBM Corporation, discloses a virtual machine having two types of heap, a private heap and a shared heap. The former is intended primarily for storing application classes, whilst the latter is intended primarily for storing system classes and, as its name implies, is accessible to multiple VMs. A related idea is described in “Building a Java virtual machine for server applications: the JVM on OS/390” by Dillenberger et al, IBM Systems Journal, Vol 39/1, January 2000. Again this implementation uses a shared heap to share system and potentially application classes for reuse by multiple workers, with each worker Java VM also maintaining a private or local heap to store data private to that particular Java VM process.
The above documents are focused primarily on the ability to easily run multiple Java VMs in parallel. A different (and potentially complementary) approach is based on a serial rather than parallel configuration. Thus it is desirable to run repeated transactions (i.e. applications) on the same Java VM, since this could avoid having to reload all the system classes at the start of each application. However, one difficulty with this is that each application expects to run on a fresh, clean, Java VM. There is a danger with serial re-use of a Java VM that the state left from a previous transaction may somehow influence the outcome of a new transaction. This unpredictability is quite unacceptable in most circumstances.
U.S. patent application Ser. No. 09/584,641 filed May 31, 2000 in the name of IBM Corporation discloses an approach for providing a Java VM with a reset capability. U.S. provisional application No. 60/208,268 also filed May 31, 2000 in the name of IBM Corporation discloses the idea of having two heaps in a Java VM. One of these is a transient heap, which is used to store transaction objects that will not persist into the next transaction, whilst a second heap is used for storing objects, such as system objects, that will persist. This approach provides the basis for an efficient reset mechanism by simply deleting the transient heap.
The techniques described above, whether involving a parallel or serial configuration, are generally designed for continuous usage without interruption, and generally entail a more complicated interaction with an application. They are therefore primarily intended for a server environment. In contrast, a PersonalJava software product (now part of Java 2 Microedition, J2ME) has been developed by Sun Microsystems Inc. for use on small handheld devices (also known as pervasive, consumer or Tier 0 devices). It is believed that one of the features used by PersonalJava software is that rather than individually load system classes at start-up, a file is stored representing the heap with all the desired system classes already loaded. Thus when the Java VM is started, this file is copied en bloc to form the new heap, saving the time of loading all the classes separately. Although this technique provides a useful optimisation, it is effectively predefined in nature which limits its flexibility and scope.
In addition, in “Signing, sealing and guarding Java objects”, by Gong and Schemers, p206–216, in “Mobile Agents and Security, Springer-Verlag, July 98, Berlin, Germany it is suggested that a signed object (i.e. having a digital signature to protect against tampering) could be used “to restart a JVM from a previously saved state”. The context of this is unclear, but it is probably similar in intention to the above-described Personal Java approach.